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In Re Application Of: Chernyak et al. | Examiner: Michael D. Masinick 
Serial No. 10/686,090 | Group Art Unit: 212 

Filed: 10/14/2003 | 

For A Method for Eff... | Date: Nov. 1 5th, 2005 
/ 

RESPONSE TO OFFICE ACTION 

This is in response to the Office Action mailed 05/64/2005. 

AFFIRMATION OF ELECTION/RESTRICTIONS 

Pursuant to a telephone call with the Office on May 6, 2005 prosecution of this invention 
was focused on Group I, claims 1-67; and this election is hereby affirmed. 

DRAWINGS CORRECTION 

The Patent Office requested correction of Figures 1 and 2 to eliminate the large dark 
arrow through the middle of the boxes. This correction has been made; and amended 
Figures 1 and 2 now have replaced the large dark arrow with arrows drawn to indicate 
flow that do not interfere with the readability of the text inside the boxes as requested. 
These drawings are otherwise unchanged and are not labeled as 'amended', but being 
marked as 'Replacement Sheet' pursuant to 37 CFR 1.121(d), as requested by the Patent 
Office. 



3 



CLAIM REJECTIONS - 35 USC $112 



The Office Action rejected Claim 46, asserting there was insufficient antecedent for the 
phrase "the human user's corrections". 

Claim 46 is dependent upon Claim 1, which specifically includes the phrases "at least one 
human user" and later "the human user", creating sufficient antecedent basis for the 
possessive apostrophe; the phrase "corrections of the human user" being grammatically 
equivalent to "the human user's corrections". 

However, as the OA rejection points out a potential misreading, Claim 46 is hereby 
amended to more closely parallel the independent claim it depends upon, to now read: 

"46. (AMENDED) A CAD-CAM software program that support Product Lifecycle 
Management as in Claim 45, further comprising a module for classifying, incorporating, 
and subsequently using a new set of defaults based on the [decisions and constraints 
entered by at least one human user] human us e r's corrections ." 
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CT.AIM REJECTION S - 35 I JSC S101/U2 

The Office Action rejected Claims 1-68 for not being supported by either asserted or well 
established utility, specifically for not being statutory to conform with current US 
practice as not reciting that the invention is a "software program embodied on a computer 
readable medium" (or an equivalent phrase) and not including, for each claim, a recited 
output to produce a tangible result. 

Applicant notes that there is no statutory support for the imposition of these requirements. 
In the absence of such statutory support, a rejection based on the lack thereof cannot be 
sustained. See the recently decided case by the PTO Board of Appeals, In Re Lundgren, 
Appeal No. 2003-2088, heard April 20, 2004, whereby just such a PTO-imposed 
requirement, the "technological arts" test under Section 1 0 1 , was eliminated. 

In In re Musgrave , 167 USPQ 280 (CCPA 1970) the Court held that a claim that recited 
physical and mental steps still constituted statutory subject matter under Sect. 101 since 
the subject matter of the claim was in the technological arts. In addition to making this 
holding, the Court also said, "All that is necessary, in our view, to make a sequence of 
operational steps a statutory process within 35 USC Sect. 101 is that it be in the 
technological arts so as to be in consonance with the Constitutional purpose to promote 
the progress of "useful arts". This statement was not necessary to the court's holding, as 
confirmed by Judge Baldwin, who dissented to this dictum, but agreed with the holding, 
stating that the statement was far too broad and unnecessary. Also in In re Toma, 575 
F.2d 872, 197 USPQ 852 (CCPA 1978), the Court reversed another non-SSM rejection 
and said, "The language [of Musgrave and another case] was written in answer to 'mental 
steps' rejections and was not intended to create a definition of statutory subject matter. 
Moreover it was not intended to for a basis for a new Sect. 101 rejection .... To the extent 
that this 'technological arts' rejection is before us ... it is reversed." 

Like Musgrave . the Toma case did not establish any technological arts "test". In Toma 
the court again reversed a rejection for non-SSM, holding that claims which involved a 
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translation from one language to another were SSM. Toma did state that such claims 
were in the technical arts, but Toma clearly did not establish any "technological arts test" 
for patentability and did not hold that the claims of a patent had to be in the technical arts 
to be patentable. 

Reliance upon Ex parte Bowman 61 USPQ2d 1665, 1671 (Bd.PatApp.&Inter., 2001) to 
support the imposition of this non-statutory claim limitation is not permitted as the 
headnote for that case explicitly states that Bowman is not intended for publication and is 
"not a binding precedent". 

The OA has not cited any cases that actually hold that claims must recite technology in a 
specific format to be patentable. Thus Applicant submits that patent claims do not have to 
recite that specific format to comply with Sect. 101. The OA has cited no legal authority 
for the assertion that a software program must be "embodied on a computer readable 
medium". However, it is hard to see how any software program either would or could not 
be so embodied, in light of optical scanning technology and text-file conversion 
programs. 

Applicant, however, does not wish to engage at this time in the expense and effort of an 
Appeal over a clause that cannot and does not change the scope of the claim and, rather 
than expend his time and money fighting a groundless and meaningless imposition, 
agrees to incorporate the phrase as a non-narrowing amendment with no effect under the 
Festo doctrine. Accordingly, Claims 1 and 40-44 have been amended to include the 
phrase "embodied on a computer readable medium" to conform with the OA practice. 

As for the requirement that each claim have a recited output, the OA overlooked the fact 
that Claim 1 (and thus, the other claims) expressly states that the invention will: 

"produce as an output at least one design of at least one product and supporting 
documentation associated with said design". 
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Admittedly Applicants invention does not specifically include a limitation that each 
produced design and supporting documentation be in either or both paper or electronic 
medium, nor in any or all of the forms of text, drawings, lists, tables, database with 
elements, or three-dimensional holographic display commands. But as both the produced 
design and documentation can be used (whether such use is to create a single item, or to 
guide the further creation of a factory line with placement, jigs, construction process 
timings, element workflow, and full assembly of tens of thousands of instantiations of the 
designed item), the utility is obvious (ask any engineer whether any product can or 
should be built without a design). Ever were the produced design not so used, the 
specification specifically alleges utility throughout - see, e.g. the text from page 40, line 
28 through to the end of page 41 and page 53, line 13, through to page 54, line 4. 
Sometimes, knowing a 'false trail' is of greater value to a corporation - and Applicant's 
invention specifically addresses, creates, and makes accessible this value as part of its 
'management' aspect. 

The physical transformation (being the transformation realized in the real world), whether 
the design be instantiated in paper or computer-readable medium, is still plain and 
evident: before this invention is used, its user is confronting an engineering problem; 
after it has been used, he has a design for a solution: To the question, there is an answer. 
To the need, there is a path to resolution. And furthermore, the design, answer, or path is 
documented and thus can be reviewed, amended, or even just comprehended by others 
than the original user - which any R&D manager would readily admit is probably of far 
greater utility to the company than the mere announcement of the design, because that 
documentation enables the subsequent production and continuing refinement. (A great 
many R&D managers would also admit, when being honest, that it often is more 
troublesome, time-consuming, and stressful to obtain the documentation than it ever is to 
obtain the design.) 

More particularly, Claims 1, 10-12, 20-23, 40-44, 54, 57, 62-63, and 68 specifically recite 
an output, as do (by dependency) Claims 13-19, 24-25, and 45-53; and Claims 2-9, 26- 
39, 55-56, 58-61, and 64-67 at worst impliedly recite an output. 
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Finally, the OA asserted that "one skilled in the art clearly would not know how to use 
the claimed invention". It is unthinkable that in today's age any person skilled in the art 
- which in this case would be "product design" - would be unable to use a software 
program. When any school-aged child can now be counted on being at least as 
competent, if not more so, than most adults to access the latest X-Box or PlayStation 
game, an assertion that a product designer could not be presumed capable of reading the 
documentation and accompanying specification concerning the operating environment 
(hardware, operating system, etc.) for the software embodying this invention is 
unsupportable by common sense. This specification need no more incorporate the details 
of such documentation than a mechanical invention need specify every physical 
characteristic of each particular part (dimensions, weight, composition, and order of 
fitting). Inasmuch as several of the dependent claims (Claims 64-66) specifically claim 
help, tutorial, corrective, and assistive elements, whereby the software helps a less-than- 
fully-skilled user through the process, this assertion is even less sustainable. 

For the above reasons, the OA rejection on this ground has been traversed. 
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CI ATM REJECTIONS - 35 USC S102 

The Office Action rejected Claims 1-3, 5-11, 36-37, 40-47 and 63 as being anticipated by 
U.S. Patent Publication 2002/0156757 (Brown, et al.). 

With respect to Claim 1 (and thus 2, 3, 5-1 1, 36-37, 40-47 and 63), the OA asserted, in 
paras. 1 1 and 12, that Brown - which itself asserts that it is "a system that provides an 
interface between different levels of a supply chain" (H0001) is anticipatory of 
Applicant's software program "which supports Product Lifecycle Management" 
(Applicant's Claim 1). Applicant's Specification (and specific detail in each of several 
dependent claims) shows that there is far more to "Product Lifecycle Management" than 
just accessing data about vendors' products. Among other things all missing entirely from 
Brown, Applicant includes documentation unification, tracking, and control (Applicant's 
Specification, p. 12, lines 18-28). There is at most a partial match between the reference 
and the invention, as the following paragraphs plainly show. 

» 

First, Brown discloses at least one "vendor database", that contains information about 
products (10016) and a "registry database" that contains the URLs for specific vendor 
databases (Fig. 1, element 34, described in f)0 19). The OA, in paragraph 12, equated 
Brown's "registry database" to a "Product Lifecycle Management Database" (Applicant's 
Claim 1). Information concerning the lifecycle of a product is not just a listing of the 
URLs for each vendor database for each of the elements that go into a product; it includes 
all elements of design and manufacture, most specifically, information about the current 
state of the process of design and/or manufacture. A URL is not "a current state of 
involvement", "customer-based Engineering Change Orders", "version tracking and 
control", "current state of the project", or any "constraints arising from corporate, rather 
than engineering, concerns" (Applicant's Specification, p. 19, last paragraph through p. 
20, first paragraph; and p. 26, line 29 to p. 27, line 4); and these are aspects of the 
Applicant's "Project Lifecycle Management Database" that are totally absent from 
Brown; even in the expanded description of the "registry database" in f)052. 
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Second, Brown discloses a "network" in one Figure (Figure 30; described in ^0046) that 
brings together "vendor databases". The OA, in paragraph 12, equated this to a 
"Collaboration Subsystem" (Applicant's Claim 1). Neither vendor data nor a network for 
bringing vendor databases together, however extensive, are information about the current 
status within the user's company of the design process for any of a number of nascent, 
partially-designed, or completed-and-in-manufacture products. Applicant's Collaboration 
Subsystem not only does not itself contain any vendor database, but instead, and 
additionally, "collects records and shares status data amongst and across the differing 
organizational groups (design teams, departments, persons, or companies) involved in the 
design process being managed by the PLM Management System" (Applicant's 
Specification, p. 27, lines 6-8). Applicant's Collaboration Subsystem also actively 
transfers information about a design and product, as the rest of that paragraph on page 27 
establishes - while Brown's network, vendor databases, and registry database, at most 
(using a generous extension over Brown's text) would enable such a transfer to be made. 

Third, Brown discloses "an interface between vendor databases and EDA tools located at 
the user workstations" (f)018). The OA, in paragraph 12, equated this to a "Project 
Management Subsystem" (Applicant's Claim 1). However, the Applicant's "Project 
Management Subsystem" incorporates all of: a Project Database; a Component Database; 
a Manufacturing Subsystem; a Purchasing Subsystem; a Component Data Management 
Subsystem; an Auto Engineering Change Order Subsystem; a Bill of Materials 
Generator; and, a Design Subsystem, which in turn incorporated each of: a Design Rules 
Check Engine; an Assembly Drawing Generator; a Verification Module; a Simulation 
Module; and; a Testing Subsystem (for Hardware and Software). (Applicant's 
Specification, p. 12, line 30 to p. 13, line 13). Brown's "interface" not only lacks at least 
six of these, but also is utterly silent about any of design rules checking, assembly 
drawings, verification, simulation, and testing activities, unlike Applicant's invention. 

Fourth, Brown discloses creating "a design file that is stored at the workstation and can 
be transported to any different design tool", (Abstract). The OA, in paragraph 12, equated 
this to producing "as an output at least one design of at least one product and supporting 
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documentation associated with said design" (Applicant's Claim 1). Brown is utterly silent 
as to either and both producing design documentation and associating that documentation 
with a resulting design. (A computer search did not find the word "documentation" 
anywhere in Brown.) 

As Applicant's invention contains elements that are not present in Brown, and eliminates 
elements that Brown deems are necessarily contained, there is no anticipation. WJ^ 
Gore & Assocs. v. Garlock. Inc. , 721 F.2d 1540, 220 USPQ 303, 313 (Fed. Cir. 1983), 
citing Soundscriber Corp- v- United States. 360 F.2d 954, 960, 148 USPQ 298, 301 (Ct. 
CI. adopted, 149 USPQ 640 (Ct. CI. 1966), cert, denied, 469 U.S. 851 (1984). 
Furthermore, these elements are not even disclosed "arranged as in the claim", as 
required by Lindermann Maschinenfabrik GmbH v. America n Hoist & Derrick Co., 730 
F.2d 1452, 221 USPQ 481, 485 (Fed. Cir. 1984), citing Connell v. Sears, Roebuck & Co. , 
722 F.2d 1542, 220 USPQ 193 (Fed. Cir. 1983). 

With respect to Claims 2, 5, and 45, as each is dependent upon Claim 1, the same 
reasoning applies. As Applicant's invention includes elements absent from Brown, the 
two cannot read on each other and no anticipation can exist. 

With respect to Claim 3 (which, as it is dependent upon Claim 1 is thus already not 
equivalent), Brown discloses "vendor-supplied data [that] can then be imported from the 
vendor-supplied database into any of the design tools". The OA, in paragraph 14, equated 
this to "a module for translation from a bill of materials for such product to a design". A 
bill of materials is a simple listing of every element where the count, not the properties, 
and the correct labeling, not the connectivity, are the important elements. A design file is 
not the same thing as a bill of materials; the latter lacks not just the 'properties data' for 
each of its elements, but also all of the design file's connective information (e.g. 'part A 
goes into slot 1 of part B'). Brown, at ^[0029, notes that 'properties data' is a crucial part 
of a design file ("In that transport process, the transport process strips away the 
mechanical properties data from the mechanical design tool file and sends the appropriate 
materials data needed by the internal database of the electromagnetic tool"; see, also Figs. 
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6-9); and also at f)031, notes that the connective information is another crucial part ("If 
there are any changes made to the mechanical design layout in the E design tool, those 
changes are reflected in the design file which is transported back to the mechanical 
design tool, if and when that design file gets transported back to the M design tool"). The 
design file is used by the engineers for product design and manufacture, but a Bill of 
Materials is used by purchasers to order parts (Applicant's specification, p. 24, lines 5-6) 
or by managers coordinating orders (Applicant's Specification, p. 30, lines 10-12). For 
the particular and separate utility of a Bill of Materials, see Applicant's Specification, p. 
44, lines 9-16; p. 30, lines 9-13; and p. 53, line 23. Brown cannot be read as incorporating 
a "Bill of Materials" in his description of a "design file", for Brown requires information 
(concerning connectivity and qualities) about the component parts that Applicant's 
invention is completely indifferent to for this element. As Applicant's invention includes 
elements absent from Brown, the two cannot read on each other and no anticipation can 
exist. 

With respect to Claim 6 (which, as it is dependent upon Claim 1 is thus already not 
equivalent), Brown is at most partially anticipatory. The OA, in paragraph 16, equated 
the sub-elements of Claim 6 to Brown's "design file 16, containing one or a collection of 
files having all of the information that the particular EDA tool needs to view, print, 
transmit, analyze and/or manipulate that particular design" fl|0064). But nowhere does 
Brown discuss "document unification, tracking, and control" (as above noted, Brown is 
silent on the entire aspect of Product Management that is concerned with documentation); 
nowhere does Brown discuss Engineering Change Order processing (Applicant's 
Specification, p. 9, lines 10-12; p. 19, lines 20-21; p. 23, lines 25-26; and most 
particularly, p. 29, line 16 through p. 30, line 7. Brown is silent as to identifying 
Engineering Change Order (ECO) requests; using unique identifiers to avoid confusion; 
accounting for personnel responsible for the ECO decisions; and the entire issue of 
managing changes (as opposed to the far simpler task of just making a change). Brown is 
further silent about coordinating design changes; for Brown only envisions a particular 
design. Brown provides an interface between databases and software design tools, yes; 
but is utterly silent on providing means for managing using those databases and tools, 
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that is, the process of managing efforts to design and manufacture products - which is the 
focus of Applicant's invention. The latter is an outward or upward step in complexity that 
is unanticipated, though it will be assisted, by the previous work. As Applicant's 
invention includes elements absent from Brown, the two cannot read on each other and 
no anticipation can exist. 

With respect to Claim 7, a typing error scrambled the phrasing and the claim has been 
amended. However, in Claim 7 (which, as it is dependent upon Claim 1 is thus already 
not equivalent) as with Claim 6, Brown is at most partially anticipatory. The OA, in 
paragraph 17, noted that "sharing among human users is done using the design files", and 
called attention to 1J0047-51. Brown also requires that each vendor database be associated 
with a unique URL [f 0050]- a limitation not required by Applicant. Managers, it must be 
emphasized, do not use the same information as engineers - and Brown's interface does 
not include any means to provide status or project reports beyond the raw 'design files'. 
Applicant, on the other hand, in Claim 7 additionally includes sharing between the 
software program and the human user both "reports concerning each project and design 
managed" and "information concerning status for each project and design" - elements 
totally absent from Brown. This information will be useful to humans in the company 
beyond the design and/or production engineers, as Applicant's Specification shows (p. 
26, lines 21-26; and allows coordination amongst different and distinct projects as well as 
designs (ibid, p. 36, lines 4-7), functional aspects entirely missing from Brown. As 
Applicant's invention includes elements absent from Brown, the two cannot read on each 
other and no anticipation can exist. 

With respect to Claim 8 (which, as it is dependent upon Claim 1 is thus already not 
equivalent), the OA, in paragraph 18, equated a workstation "with access to records 
stored in the databases of figure 1" with Applicant's Product Lifecycle Management 
database and more specifically, "all records used by the CAD-CAM software program to 
control and coordinate all activities between the database and subsystems; and, all 
records used by the CAD-CAM software program to record, track, update, and report on 
the full lifecycle for each project and product handled by the CAD-CAM software 
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program by the CAD-CAM software program to record, track, update, and report on the 
full lifecycle for each project and product handled by the CAD-CAM software program". 
However, the PLM Management Database specifically contains records which are used 
"to record, track, update, and report on the full lifecycle for all projects and products 
throughout their design and manufacture" (Applicant's Specification, p. 26, line 29 
through p. 27, line 4). This includes tracking authorization for design changes 
(Applicant's Specification, p. 30, lines 2-7). Furthermore, inasmuch as there are 
subsystems in Applicant's invention that are entirely absent from Brown (see the list in 
Applicant's Specification on p. 13, which for the Project Management Subsystem alone 
includes, as noted above, multiple elements totally absent from Brown, including the 
Design Subsystem and all of its subordinate elements), Brown cannot be read to cover the 
parts of Applicant's Product Lifecycle Management Database that incorporates records 
and functionality to control and coordinate activities with those additional elements. 
Brown is, by its own admission, an interface between EDA design files; it is not software 
created for EDA design management - but Applicant's invention, is. As Applicant's 
invention includes elements absent from Brown, the two cannot read on each other and 
no anticipation can exist. 

With respect to Claim 9, (which, as it is dependent upon Claim 1 is thus already not 
equivalent), the OA, in paragraph 19, equated "design files" with both means for 
recording each product and "means for incorporating into the Project Lifecycle 
Management database each such product as a project" (Claim 9, last paragraph). Setting 
aside the first equivalence (not conceding, just focusing on the more evident flaw), the 
second equivalence cannot stand. As noted above, in Brown, a "design file" contains 
information about a designed product's elements (their physical characteristics) and those 
elements connection into a whole (their 'mechanical design layout'); but Brown does not 
include any documentation - most particularly, any recording the current, previous, or 
planned status of the design or manufacture. Furthermore, as noted above, Brown's 
design file contains no information about corporate matters (e.g. project or product design 
authority, change authorization rights, or the manufacturing responses to suggested 
substitutions (see Applicant's Specification, p. 28, line 19 through p. 29, line 7). As 
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Brown has no such information, it cannot control, or provide the means for incorporating 
any product as a project, for any of its particular design files; that must entirely be done 
by the human user of Brown's interface... optimally, Applicant would hope, with 
Applicant's much broader-purpose invention. As Applicant's invention includes elements 
absent from Brown, the two cannot read on each other and no anticipation can exist. 

With respect to Claim 10 (which, as it is dependent upon Claim 1 is thus already not 
equivalent), the OA, in paragraph 20, equated Applicant's "Collaboration Subsystem" 
with "vendor databases" (10062). Brown makes no mention of the "automatic 
messaging" in Applicant's Collaboration Subsystem (Specification, p. 27, lines 8-11); or 
of scheduling processes (ibid, p. 36, lines 9-13); nor does Brown make any mention of 
including "status data as outputs" in either the "vendor databases" or the "design files" 
mentioned in Brown. As Applicant's invention includes elements absent from Brown, the 
two cannot read on each other and no anticipation can exist. 

With respect to Claim 1 1 (which, as it is dependent upon Claim 1 is thus already not 
equivalent), the OA, in paragraph 21, equated Applicant's "status data" and "automatic 
messaging" with ways of handling imported data. This equation is flawed on two 
grounds. First, the data referenced arises from entirely different sources. Applicant 
respectfully points out that Brown's "imported data" references data imported from a 
vendor [10061, "vendor-supplied data"; 10062, both "vendor-supplied data" and "vendor- 
supplied database icon"; 10063, "import the standardized database data provided in 
vendor supplied databases"; 10065, "the standardized vendor-supplied data"; 10066, "the 
vendor-supplied data"; 10067, "that standardized data from the vendor supplied 
databases"; 10068, "the standardized vendor-supplied data"]. But Applicant references 
data generated outside of a vendor - namely, the status data of a product's design and 
manufacture within the user's company. This is, to put it mildly, highly confidential 
information that is at best reluctantly shared with vendors, but never produced by 
vendors. The source of Brown's data is from an outside vendor; the source of Applicant's 
user's status data is the user and his collaborators. 
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Second, as pointed out above, there is a great deal of difference between the engineering 
specifics that comprise Brown's "design files" and "vendor- supplied data", and 
Applicant's management specifics that comprise "status data". 

Because the source, and nature, of the information that is being handled is entirely 
different, the equivalence is unsupportable, and Brown cannot anticipate Applicant's 
invention. 

With respect to Claims 46 and 47, (which, as each is dependent upon Claim 1 is thus 
already not equivalent), the OA (in paragraph 23) equated Brown's Neutral Dynamic 
Hub with Applicant's module for classifying, incorporating, and subsequently using a 
new set of defaults in a design. Brown, in f0026, noted that his Neutral Dynamic Hub 
allowed the transfer of vendor-supplied data and design files between various EDA tools, 
and in ^[003 1 allowed changes made in one EDA tool to be reflected and kept when the 
design file is transported back (or over) to a first (or third) EDA tool. The intervening 
paragraphs of Brown made it clear that the Neutral Dynamic Hub was assuring that all 
the properties data and design layout for a particular design was maintained across 
different EDA tools (mechanical, or electrical). 

In contrast, Applicant's invention specifically mentions both incorporating "pre-loaded 
defaults' and 'learning new starting defaults' (p. 40, lines 3-5). Brown is silent about 
defaults (a computer search does not produce the word). Brown's interface, however 
much it may allow access to and incorporation of a vendor's database, does not itself 
include any default design. Brown does not mention including a pre-loaded, default 
library of HES designs. Nor does Brown address the concept of 'classifying' design files 
- which could mean, after having transferred a design file using Brown's Neutral 
Dynamic Hub across two or three different sub-field EDA tools, finding the most current 
version of the file could be... conflicted, difficult, or even impossible without the 
knowledge of a no-longer-employed worker. Applicant's module, like any management 
tool, includes the means to classify, order, and thus make retrievable complex project 
documents without having to know their contents, vendor origin, or specifics. As 
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Applicant's invention includes elements absent from Brown, the two cannot read on each 
other and no anticipation can exist. 

With respect to Claim 63, it is dependent upon Claims 1 and 36, and the same reasoning 
applies to it as to those. As Applicant's invention includes elements absent from Brown, 
the two cannot read on each other and no anticipation can exist. 

With respect to all objections under 35 USC §102, the reality of R&D is simply that the 
status of a design is, to a cooperative entity comprised of multiple individuals and groups 
collaborating together, a far different thing than the design itself. This can be realized 
with two quick rhetorical questions: when considering whether to invest in manufacturing 
capacity, do managers ask first about the status of a design (i.e. "Is it done?"); do they ask 
about the non-engineering details of a design ("How much will it cost?"); or do they ask 
about the engineering details ("From whom are we going to get the core chipset?")? And, 
when different groups attempt to collaborate, do they first dump over all the design files, 
or do they ask for status and authorization reports so they can know who has the 
personnel and bandwidth to deal with the project associated with a particular design? To 
ask the questions is to answer them - and highlight the critical differences between 
Brown and Applicant's invention. Because to Brown's interface, these questions are 
meaningless, unanswerable - but to Applicant's invention, they address the core of its 
value. 

For these reasons, the above rejections are traversed, and the Applicant respectfully 
requests that they be allowed to proceed to issue, as amended. 



17 



CLAIM REJECTIONS - 35 USC S103 



The Office Action rejected Claims 4, 64 and 66 as being rendered obvious by U.S. Patent 
Publication 2002/0156757 (Brown, et al.) combined with another reference. 

Claim 4 is rejected as being unpatentable over the combination of Brown and U.S. Patent 
4,862,376 (Ferriter, et al.). Specifically, the OA noted (in para. 28) that Ferriter "shows a 
module for translation from an engineering drawing for such product to a design" 
(Ferriter Fig. 12; Abstract). 

The abstract is entirely silent as to any such module, saying only that "From this file an 
image of the bill of materials can be displayed in the CAD/CAM environment. The 
designer can use this image as an aid in the design process. Item names and numbers can 
be copied from the displayed bill of materials to the CAD/CAM image. The bill of 
materials can also be edited in the CAD/CAM environment and the edited bill of 
materials can then be reconstructed in the conceptual design tool for use in the continuing 
design and planning process." (Abstract.) 

As Ferriter describes his invention, it involves using a Bill of Materials, which "becomes 
a menu for selecting standard drawings to aid in the design process" (col. 1 1 , lines 1 5- 
17). However, even if a standard drawing is selected, it is only incorporated as a drawing. 
Ferriter explicitly stating that this ability "greatly simplifies the drawing, and hence the 
design, process" (col. 12, lines 21-22), concedes that there is yet another step between 
creating a drawing and creating a design. 

Brown's application, as noted above, only discloses an "interface", or means for sharing 
information across different vendor databases and EDA tools. If Ferriter is combined 
with Brown (and neither the references not the Examiner cite any source for such), then 
one gets a computer interface for sharing drawings across EDA tools. 
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None of the elements previously identified as being absent in Brown but present in Claim 
1 ( including specifically the documentation unification, tracking, and control 
(Applicant's Specification, p. 12, lines 18-28), information concerning the lifecycle of a 
product especially most specifically, information about the current state of the process of 
design and/or manufacture, or an Auto Engineering Change Order Subsystem; a Bill of 
Materials Generator; and, a Design Subsystem, which in turn incorporated each of: a 
Design Rules Check Engine; an Assembly Drawing Generator; a Verification Module; a 
Simulation Module; and, a Testing Subsystem (for Hardware and Software (Applicant's 
Specification, p. 12, line 30 to p. 13, line 13)), are present in Ferriter or suggested by the 
combination of Ferriter and Brown. For Brown and Ferriter address only the creation of a 
single design, and are silent as to the management of the design process - and most 
particularly, as to the auxiliary materials and records concerning the project's status, 
which often are as important as the design files themselves to the successful development 
and manufacture of a product from a design. 

Applicant's Claim 4 and 64 depend on Claim 1, and for the above reasons, the OA's 
rejection is deemed traversed, and this claim is respectfully ready to issue. 

Claims 65-66 are rejected as being unpatentable over Brown, despite the fact that the OA 
concedes that the latter includes no mention of an Interactive Help Module of Claim 64 
nor any of the specific limitations claimed in Claims 65 and 66. There is only an assertion 
that "fhjelp menus and tutorial menus are well known parts of a software program" (OA 
paragraph 33). Help menus and tutorial menus for a software program focus on the 
operation and use of the program - at least those disclosed by the OA, which arise from 
"all programming systems for creating windows programs". These do not contain any of 
the substantive material for the field of the software program - otherwise, these same 
programming systems would have to both contain source material for all possible 
substantive knowledge fields and means to particularly attach only that minute sub-set 
relevant to the substantive field of the created program. (Which capacity, incidentally, 
would violate an extension of Turing's Halting Problem.) The windows programming 
tools do not know about electronic engineering, financial management, business 
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operations, physics, geology, language translation, statistical analysis, law, art, 
or other substantive fields; they simply know how to design a program. 



Accordingly, the automatically-created help menus and tutorials do not provide 
substantive material relating to the field in which the software program operates such as 
the "general engineering library with incorporated references" and "technical overview 
for each field of engineering contained within the database and subsystems", specifically 
mentioned in Claim 65. 

Similarly, tutorial menus for a software program teach the user how to use the software 
program; they do not incorporate training material in the substantive field as does Claim 
65, which specifically incorporates: a set of design challenges; for each design challenge, 
a previously-worked-out solution set of satisfactory designs; and, instruction for relative 
evaluation of the members of the solution set against the constraints and decisions which 
produced each member of the solution set. 

The addition of substantive material relevant to the particular design field(s) for the 
Applicant's program differentiates the final product from one containing merely help and 
tutorial assists that teach the user how to use the program - and such 'how to use this 
program' efforts are not what Applicant seeks to claim in Claims 64-66! Because the OA 
failed to distinguish between these different categories of 'process' and 'substantive' help 
and tutorial efforts, the evaluation of 'obviousness' from 'programming systems for 
creating windows programs' is flawed and unsupportable. For this reason, the rejection is 
traversed and the claims should be allowed to issue. 
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ALLOWABLE SUBJECT MATTER 



In the OA, Claims 12-35, 38-39, 48-62, and 67 were objected to as being dependent upon 
a rejected base claim, but otherwise allowable if rewritten into independent form (OA, 
para. 34) and all USC 101/1 12 rejections were removed. 

Applicant believes that the rejection of independent Claim 1 has been traversed for the 
grounds given above. As Claims 2-11, 36-37, and 63-66 are dependent upon Claim 1, 
this traversal applies equally to them. 

Applicant is open to discussion through a telephone interview, should the Office decide 
that the rejection of Claim 1 has not been traversed, of the redrafting of the claims herein. 
To assist with the continued effort and cooperation between the Office and Applicant, 
some outline of the possibilities follows. 

In light of Ferriter and Brown, Claims 3-5 could be either replaced by a similar claim 
that is dependent upon a later-occurring, but acceptable, independent claim (e.g. a re- 
written Claim 12); or incorporate a specific limitation requiring the incorporation of 
product (not "design file") specific data as part of the translation process. As Claims 6-9 
already incorporate product or project data beyond the reach of Ferriter and Brown, these 
should be allowed; but again, they could be replaced by a similar claim dependent upon a 
later-occurring, but acceptable, independent claim. Lastly, although Applicant believes 
that Claims 10 and 1 1 also incorporate "status data" that puts them beyond the reach of 
Ferriter and Brown, these should be allowed; but they either could be replaced in like 
fashion or amended to incorporate a specific limitation as to the nature of the data to 
more clearly distinguish them from Brown's material-related data [1(0093, 0094], which 
he also calls "materials data" [1(0096]. 

The OA indicated that Claim 12 would, upon incorporating all of the prior limitations, be 
allowable if rewritten as an independent claim. It then should be acceptable to have 
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Claims 36, 37, 39, 40-45, and 67 be made dependent upon Claim 12, which would make 
them also allowable. This should also make Claims 46, 47, and 63-66 allowable. 

Applicant is further willing to discuss the potential of a specific differentiation to Claim 
64 as to including into that claim a limitation specifically addressing the nature of the 
substantive content of an Interactive Help Module to distinguish it, as the Specification 
indicates, from any Help module solely designed to assist a user with the computer- 
interaction features of the software program. 
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For all of the above grounds and reasons the Examiner is respectfully requested to allow 
the claims. 

If the Examiner has any questions or wishes to discuss this matter he is urged to 
telephone the Applicant's attorney, George S. Cole, Esq., at (650) 322-7760; or may 
direct an e-mail communication to the same individual via the e-mail address of 
GSCdLawyer@aol.com. 

A claims listing with the status of each claim, with the claims in ascending order, and 
with the text of the currently-amended claim, has been appended to this Response. This 
listing of claims will replace all prior versions, and listings, of claims in the application. 

As so corrected, the Applicant believes that these claims are now all in presently 
allowable, correct, and proper form, and respectfully asks that a timely Notice of 
Allowance be issued in this case. 



495 Seaport Court, Suite 101 
Redwood City, CA 94063 
Tel: (650) 322-7760 
Fax:(650) 322-6117 
GSCdLawy er@aolxom 



Respectfully Submitted: 
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